1. Field of the Invention
The present invention generally relates to a mobile communication system, and more particularly to a system and method for state synchronization between a base station and a mobile station in a mobile communication system using frequency multiplexing.
2. Description of the Related Art
An Institute of Electrical and Electronics Engineers (IEEE) 802.16 communication system performs communication using connection information negotiated between a subscriber station and a base station.
FIG. 1 schematically illustrates a structure of the conventional IEEE 802.16 communication system.
In relation to FIG. 1, a wireless Metropolitan Area Network (MAN) communication system serving as a Broadband Wireless Access (BWA) communication system supports a wider service area and a higher transmission rate than a wireless Local Area Network (LAN) communication system. The IEEE 802.16 communication system employs Orthogonal Frequency Division Multiplexing (OFDM) and/or Orthogonal Frequency Division Multiple Access (OFDMA) for supporting a broadband transmission network in a physical channel of the wireless MAN communication system. That is, the IEEE 802.16 communication system is a BWA communication system using an OFDM/OFDMA scheme.
Because the IEEE 802.16 communication system employs the OFDM/OFDMA scheme in the wireless MAN communication system, a physical channel signal can be transmitted through a plurality of subcarriers, and therefore high-speed data can be transmitted.
Referring to FIG. 1, the IEEE 802.16 communication system has a multi-cell structure, i.e., cells 100 and 150, and is provided with a Base Station (BS) 110 for covering the cell 100, a BS 140 for covering the cell 150, and multiple Mobile Stations (MSs) 111, 113, 130, 151, and 153. Signal transmission and reception between the BSs 110 and 140 and the MSs 111, 113, 130, 151, and 153 are performed using the OFDM/OFDMA scheme.
FIG. 2 illustrates a network reference model of a conventional mobile communication system.
Referring to FIG. 2, the network reference model is configured with MSs 210 and 220, BSs 230 and 240, and an Authentication and Service Authorization (ASA) server 250.
Communication between the MS 210 or 220 and the BS 230 or 240 is performed through a “U” interface. The “U” interface is an interface in which operations of a Physical (PHY) layer and a Media Access Control (MAC) layer and a message exchange-related operation are defined.
Communication between the BSs 230 and 240 is performed through an “IB” interface. The “IB” interface is an interface in which message transmission operations relative to information about an MS for which a handover is performed, a BS state, a request to an opposite BS, and so on are defined.
On the other hand, communication between the BS 230 or 240 and the ASA server 250 is performed through an “A” interface. The “A” interface is an interface in which an operation and function between the BS 230 or 240 and the ASA server 250 are defined for an authentication procedure of the MSs 210 and 220.
FIG. 3 illustrates an internal structure of the BS in the conventional mobile communication system.
Referring to FIG. 3, the BS is provided with a Control Processor Unit (CPU) 310, OFDMA PHY Units (OPUs) 315 and 320, Channel Units (CHUs) 325, 330, 335, and 340, and a Network Processor Unit (NPU) 345. The components are connected to system buses (BUSs). Data and control information are transmitted and received through the BUSs.
The OPUs 315 and 320 demodulate and decode OFDMA symbols received in various frequency bands to extract data, or encode and modulate data into OFDMA symbols. That is, the OPUs 315 and 320 decode OFDMA data signals received from the MSs, extract MAC frames to transfer the extracted MAC frames to the associated CPU, or encode MAC frames received from the CHUs 325, 330, 335, and 340 into OFDMA symbols to transmit the OFDMA symbols to the MSs.
The CHUs 325, 330, 335, and 340 generate high-layer Protocol Data Units (PDUs) (e.g., Internet Protocol (IP) packets) from the received MAC frames, or divide high-layer PDUs into MAC frames. That is, the CHUs 325, 330, 335, and 340 collect the MAC frames via the BUS from the OPUs 315 and 320 to generate the high-layer PDUs and transfer the generated high-layer PDUs to the NPU 345, or divide the high-layer PDUs received from the NPU 345 into the MAC frames to transmit the MAC frames to the OPUs 315 and 320. The NPU 345 performs a function for communicating with a network connected to the BS, i.e., the BS or ASA server.
The CPU 310 is responsible for all control functions of the BS. That is, a command for performing a function mapped to an instruction input from a BS operator is transferred to all the units.
As illustrated in FIG. 3, the BS has a structure capable of processing data of the MSs to transmit the processed data using the “IB” or “A” interface even though the CPU is disabled or uninstalled due to failure. The system has a structure in which a function of the BS is not affected even though one unit is disabled or uninstalled.
FIG. 4 schematically illustrates a downlink (DL) frame format in a mobile communication system using OFDM/OFDMA. Specifically, FIG. 4 schematically illustrates the DL frame format of the IEEE 802.16 communication system.
Referring to FIG. 4, the DL frame is provided with a preamble portion 400, a broadcast control portion 410, and a plurality of Time Division Multiplexing (TDM) or Time Division Multiple Access (TDMA) portions 420 and 430. A synchronization signal for synchronization acquisition between the BS and the MS, i.e., a preamble sequence, is transmitted in the preamble portion 400.
The broadcast control portion 410 is provided with a Frame Control Header (FCH) field 415, a DL_MAP field 411, and an Uplink (UL)_MAP field 413. Herein, the FCH field is illustrated as a Downlink Frame Prefix (DLFP) field in which DLFP information is transmitted in FIG. 4. The DLFP format is shown in Table 1.
TABLE 1SyntaxSizeNotesDL_Frame_Prefix_Format( ) {Used subchannel6 bitsBit #0: Subchannels 0-11bitmapare usedBit #1: Subchannels 12-19are usedBit #2: Subchannels 20-31are usedBit #3: Subchannels 32-39are usedBit #4: Subchannels 40-51are usedBit #5: Subchannels 52-59are usedReserved1 bitShall be set to zeroRepetition_Coding_Indication2 bits00 - No repetition coding onDL-MAP01 - Repetition coding of 2used on DL-MAP10 - Repetition coding of 4used on DL-MAP11 - Repetition coding of 6used on DL-MAPCoding_Indication3 bits0b000 - CC encoding used onDL-MAP0b001 - BTC encoding used onDL-MAP0b010 - CTC encoding used onDL-MAP0b011 - ZT CC used onDL-MAP0b100 to 0b111 - ReservedDL-Map_Length8 bitsReserved4 bits
As shown in Table 1, the DLFP field includes a plurality of Information Elements (IEs). The IEs are a used subchannel bitmap for indicating the number of subchannel groups used in a partial usage subchannel zone of a DL frame, a repetition coding indication used in the DL_MAP, a coding indication for indicating a modulation and coding scheme used to transmit the DL_MAP, and a DL_MAP length.
The DL_MAP field 411 is a field in which a DL_MAP message is transmitted. IEs included in the DL_MAP message are shown in Table 2.
TABLE 2SyntaxSizeNotesDL-MAP_Message_Format( ) {Management Message Type = 2 8 bitsPHY Synchronization FieldVariableSee appropriate PHY specificationDCD Count 8 bitsBase Station ID48 bitsNumber of DL-MAP Elements n16 bitsBegin PHY Specific Section {See applicable PHY sectionfor (i = 1; i < = n, i++) {For each DL-MAP element 1 to nDL_MAP_Information_Element( )VariableSee corresponding PHY specificationif !(byte boundary) {Padding Nibble 4 bitsPadding to reach byte boundary}}}}
As shown in Table 2, the DL_MAP message includes a plurality of IEs. The IEs are a management message type corresponding to a type of message to be transmitted, a PHY synchronization field mapped to modulation and demodulation schemes applied to a physical channel for synchronization acquisition, a Downlink Channel Descriptor (DCD) count mapped to a configuration change of a DCD message including a DL burst profile, a BS identifier (ID), and the number of DL_MAP elements, n, subsequent to the BS ID.
To decode the DL burst profile, DL-MAP IEs are mapped to DCD messages for indicating modulation and coding schemes and physical characteristics in a one-to-one correspondence. That is, the DCD message includes the DL burst profile. Thus, the MS receives the DL-MAP message and must know in advance the DCD information before decoding the received DL-MAP message.
IEs included in the DCD message are shown in Table 3.
TABLE 3SyntaxSizeNotesDCD_Message_Format( ) {Management Message Type = 18 bitsDownlink channel ID8 bitsConfiguration Change Count8 bitsTLV Encoded information for theVariableTLV specificoverall channelBegin PHY Specific Section {See applicable PHYsectionfor (i = 1; i < = n, i++) {For each downlinkburst profile 1 to nDownlink_Burst_ProfilePHY specific}}}
As shown in Table 3, the DCD message includes a plurality of IEs. The IEs are a management message type corresponding to a type of message to be transmitted, a used DL ID, a configuration change count mapped to a configuration change of DL channel information, Type/Length/Value (TLV) encoded information for the overall channel, and a PHY specific section. The UL-MAP field 413 is a field in which a UL-MAP message is transmitted.
As described above, the CPU of the BS is responsible for the overall control of the BS in the IEEE 802.16 communication system. In other words, the CPU manages the BS configuration/setup information, information about a connection with the MS, the state information of the MS (e.g., information about the MS sleep mode, normal state, and idle mode), and the MS configuration/setup information, and performs proper operations mapped to a plurality of occurred events. When an unexpected error occurs in the CPU or an operator restarts the CPU, the MS may never know it. Thus, when the CPU has been reset and restarted, the MS continuously transmits its own data traffic in a state in which it does not know that the CPU has been reset and restarted. In this case, the CPU cannot manage an associated MS because connection, state and configuration information managed by the CPU is absent due to the reset.
In other words, an MS transmits UL data using a connection ID (CID) already assigned before the reset of the CPU, but the BS may never know a CID used in an MS for receiving a service. Thus, a real need exists for a method capable of maintaining state synchronization between the BS and the MS when the CPU of the BS is reset.